@jamesobutler thank you so much for the contribution!

I asked Copilot about the failing test, and this was the (most relevant, I think, part of the) response:

This is a static type-checker error (mypy), not a runtime ImportError. The code does try/except ImportError but mypy still resolves the attribute from the pydicom stubs used in CI and complains when it can't find parse_basic_offsets in those stubs.

Replace the direct conditional import with a safe getattr-based resolution. This avoids mypy trying to validate module attributes at import time and keeps runtime compatibility with both older and newer pydicom.

from typing import Any, Callable, Optional
import pydicom.encaps as _pydicom_encaps  # type: ignore

# Resolve functions dynamically (use getattr so mypy does not require the attribute in stubs)
_parse_basic_offsets: Optional[Callable[..., Any]] = getattr(
    _pydicom_encaps, 'parse_basic_offsets', None
)
_get_frame_offsets: Optional[Callable[..., Any]] = getattr(
    _pydicom_encaps, 'get_frame_offsets', None
)

if _parse_basic_offsets is not None:
    parse_basic_offsets = _parse_basic_offsets  # type: ignore
    _use_parse_basic_offsets = True
elif _get_frame_offsets is not None:
    get_frame_offsets = _get_frame_offsets  # type: ignore
    _use_parse_basic_offsets = False
else:
    # Should not happen for a standard pydicom install. Make the error explicit.
    raise ImportError(
        'Neither parse_basic_offsets nor get_frame_offsets available in pydicom.encaps'
    )

Or we could just require latest pydicom?

@pieper @CPBridge what would you recommend?

The mypy check should no longer fail following dropping of end-of-life Python 3.9. The Python 3.9 CI install of the application is pulling pydicom 2.4.4 because pydicom 3 requires Python 3.10+. I have added testing for Python 3.14 following the drop of Python 3.9. Whenever dicomweb-client last dropped python version support, the justification was because they were end-of-life versions as well (see #113).

I would recommend a v0.61.0 release considering the python requirements will have changed. Similarly in dicomweb-client v0.60.0 there was a bump in the python requirement.

I do not think it's a good idea to try and support pydicom across the major version change 2.x to 3.x. I would favour requiring pydicom>=3.0.0 and removing the import hackery

I am also on board with dropping 3.9 support now that it is EOL

@jamesobutler I merged #121, could you please remove those changes from this PR

Yes, I'll rebase this branch upon integration of #122.

I would favour requiring pydicom>=3.0.0 and removing the import hackery

I was thinking the same, but wanted to hear from Chris or Steve, since they have a lot more experience with python.
@jamesobutler let's do pydicom>=3.0.0!

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

Todo:

• Handle addition deprecations when using pydicom >=3 such as DeprecationWarning: 'Dataset.is_little_endian' will be removed in v4.0, set the Transfer Syntax UID or use the 'little_endian' argument with Dataset.save_as() or dcmwrite() instead